ModuleRef is a reference to the current module's DI container. Inject it to resolve providers imperatively at runtime — useful when you need a provider conditionally or need to retrieve a transient/request-scoped provider dynamically. Use moduleRef.get() for singletons and moduleRef.resolve() for scoped providers.
Strategy pattern — dynamically choose which provider to use at runtime.
Lazy initialization — resolve a heavy provider only when first needed.
Factory services — create instances of transient providers on demand.
moduleRef.get() is synchronous and only works for singleton providers.
moduleRef.resolve() is async and creates a new DI sub-context for scoped providers.
You need to get an instance of a service inside a NestJS guard, but you can't inject it via the constructor. How would you use ModuleRef to retrieve it?
If you call moduleRef.get(MyService, { strict: false }) and the provider isn't registered, what will happen at runtime?
What would be the result of requesting a request‑scoped provider using ModuleRef from within a singleton?
During a feature rollout you want to lazily load a heavy third‑party client only when a specific endpoint is hit. Walk me through how you'd use ModuleRef to achieve that and the trade‑offs you consider.
Your app started throwing 'Nest can't resolve dependencies' after moving a provider into a dynamic module. How could ModuleRef help you debug or fix the issue?
You have a plugin system where modules are registered at runtime. How would you use ModuleRef to instantiate a plugin's service and ensure its dependencies are satisfied?
At high traffic you notice that using ModuleRef.get inside a controller adds latency. What strategies would you employ to mitigate the performance impact while keeping dynamic resolution?
Design a mechanism for hot‑reloading feature modules without restarting the NestJS app. How would ModuleRef be involved, and what edge cases must you handle?
Explain how you would coordinate ModuleRef usage across multiple microservices that share a common library, ensuring consistent provider instances.
Your organization is migrating a monolith to a modular NestJS architecture. How would you leverage ModuleRef to gradually refactor code, and what governance policies would you set to avoid runtime injection pitfalls?
When several teams add dynamic modules that rely on the same token, what architectural guidelines would you establish around ModuleRef usage to prevent token collisions and maintain testability?
Consider a long‑running background job system that resolves providers at runtime based on a job type stored in a database. How would you design this using ModuleRef to be resilient to schema changes and versioned modules?